HATEOASについての説明はつかみ所が無いと悪名高いのだが、それをより簡単にするためにNick Gall氏は、HATEOASをdomain specificなプロトコル記述のためのエンジンとして説明するという考え方を検討している。Gall氏によれば、HATEOASは従来、次のように説明されている。
（前略）強調されているのは、HATEOASにおいてサーバレスポンスに求められるものがリクエストデータだけでなく、次にサーバに対して行うことが許されるアクションを記述した制御情報も含むということです（これは特別にタグづけされたURLの形式をとります）。この追加された制御情報（少なくとも他のデータに対するいくつかのリンク）こそが、単なるメディアをハイパーメディアへと変えるのです。
Gall氏は自身がwebインターフェイス（つまりRESTfulインターフェイスでもあるのだが）をどうとらえているのかを、識別子（Uri）、フォーマット（HTML）、プロトコル（HTTP）（合わせてIF and P）という用語で説明している。Gall氏によれば、HATEOASを用いたRESTfulなアプリケーションのことをこれら3つの構成要素（IF and P）の集合だと考えうるのは事実であるが、ハイパーメディアに関しては、domain specificなプロトコル記述であると考えた方が理解する上では適切だという。Gall氏はJim Webber氏の「Restbucks」を題材にした発表を取りあげ、そこでハイパーメディアの使用がプロトコル記述として説明されていると指摘している。
これは一見すると直観に反しているように見えます。というのも、WWWにおいてはHTTPがプロトコルであり、HTMLはフォーマットであると前述していますから。しかし、URL、HTML、HTTPはdomain specificな識別子、フォーマット、プロトコルを説明するための汎用的な記述言語に過ぎないのです。ですから、特定のHTMLページが集まったウェブのことをdomain specificなプロトコルと考えて下さい。
この「ハイパーメディアがプロトコルを記述する」という考え方は、WS-BPEL 1.1仕様やWADLと比較することを避けて通れない。Gall氏はこう語る。
根本的な違いはWS-BPELが基づいている考え方が、静的なプロトコル記述の全体をアップフロントに一度だけ、それも今までとは違うやり方で規定するものである点にあります。HATEOASが基づいているのは漸進する記述という考え方です。他にいい表現があるとすれば、JITプロトコル記述（Just In Time）でしょうか。（中略）言ってみれば「各サーバレスポンスは漸進的に現在のプロトコルについて自ら記述する」のです。
このJITプロトコル記述はアップフロントな記述と比べると良い点も悪い点もあり、それはツールのサポートやこれらのインターフェイスの見つけやすさにかかっている。さて、「ハイパーメディアがプロトコルを記述する」という考え方は、HATEOASに対する認識を考える上での新しい方法なのだろうか？そして、これで分かりやすくなるだろうか？